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Remarks 



This amendment is filed in response to an Office Action mailed 9/9/2005 
("Office Action"). In this Office Action, Claims 1 -32 were rejected. Claims 1 -32 
remain pending. In the amendment set forth above, Claims 1 , 2, 4-6, 8, 10, 14, 
24, and 31 are amended, and the remaining Claims are as previously presented. 
In view of the amendments to the Claims and the comments set forth below, it is 
submitted that all Claims are in condition for allowance. 

1 . Claims 1 -32 were rejected under 35 USC §1 02(e) as being anticipated by 
U.S. Patent Application US2003/01 45210 to Taylor ("Taylor"). This rejection is 
respectfully traversed. 

As currently amended, Claim 1 describes a method for allowing a request 
that is any one of multiple request types to gain access to a resource. According 
to the method, multiple thresholds are defined. Each threshold is associated with 
one or more of the request types, and at least one of the request types is 
associated with multiple thresholds. (Claim 1 step b.) 

The aspect of the invention described above in shown in Applicants' 
Figure 3. In that figure, request types are shown as % Y, and Z". These 
requests may comprise read requests, write requests, and high-priority read 
requests, for instance. As may be noted, it is possible to define a threshold that 
is associated with multiple request types, as is claimed by Applicants' Claim 1 . 
For instance, threshold 1 of Figure 3 is associated with request types X, Y and Z. 
Conversely, it is possible to associate a request type with multiple thresholds, as 
is also claimed by Applicants' Claim 1 , as amended. For Instance, in Figure 3, 
request type X is associated with all of thresholds 1, 2, and 3. This provides a 
very flexible mechanism for controlling the types of requests that gain access to a 
resource. For instance, even after Threshold 1 has been exceeded, some of the 
requests that are of a type associated with that threshold may still gain access to 
the resource if the type is associated with a different threshold. 



10 

PAGE 1 1/21 * RCVD AT 1/9)2006 6:59:49 PM [Eastern Standard Time] * SVR:USPTO-EFXRF-6/27 * DNIS:2738300 * CSID:651 635 7990 * DURATION (mm-ss):06-26 



01/09/2006 MON 18:01 FAX 651 635 7990 



UGS 



©012 



Serial No 10/675,784 
Filed 9/30/2003 
Examiner Christopher Shin 



Office Action Response 
January 9, 2006 
Group Art Unit 2182 



Next, Taylor is considered. The Examiner states that the Taylor shared 
resources 24a - 24n teach Applicants' shared resource, and the Taylor read and 
write requests teach Applicants' request types. (Taylor page 3, lines 4-6.) The 
Examiner further states that Applicants' threshold values are taught by the 
numbers of requests that are limited and utilized by elements 50, 70, 72, 90, and 
1 1 0. (Taylor page 3 lines 7-9.) This last statement is not completely 
understood. 

As best understood from Taylor, the number of read requests that may 
gain access to a shared resource is controlled by the allowed readers field 96 of 
Taylor Figure 3 as follows: 

"As allowed readers field 96 indicates a maximum number of 
processes/threads that can be simultaneously granted read access to the 
shared resource 24a, 24b,. ..24n". (Taylor paragraph 0029.) 

From this paragraph, the allowed readers field 96 limits the number of read 
requests to a resource, and thus it would appear the Examiner is citing this field 
as teaching a threshold for controlling the number of read requests that gain 
access to a shared resource. If this understanding is not correct, and this 
rejection is maintained, clarification is requested. 

In regards to write requests, only a single write request can gain access to 
a shared resource at a given time, as described in Taylor paragraph 34 (see, in 
particular, lines 1 7-22 of this paragraph.) Thus, it appears that "a threshold" 
associated with write requests is always set to "one". If this understanding is not 
correct, and this rejection is maintained, clarification is requested. 

An additional I/O request list 54 is maintained to record those processors 
or thresholds queued to perform a read or write operation to a shared resource. 
(Taylor paragraph 25.) Taylor does not appear to set any limit (or threshold) on 
the number of pending requests in this list. 
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For completeness, it may be noted that the Examiner appears to find 
significance in the "numbers of requests that are limited and utilized by elements 
50, 70, 72, 90, and 1 10". However, if the Examiner's analogy is followed such 
that the Taylor shared resources 24a - 24n teach Applicants' shared resource, 
then any thresholds that teach Applicants' thresholds must control access to the 
Taylor shared resources, as required by Applicants' Claim 1 step d., both as 
originally provided and as currently amended. Therefore, any relevance as to the 
number of requests that are accessing the other elements 50, 70, 72, 90, and 
110 besides the shared resources 24 within the Taylor system is not understood. 
If this rejection is maintained, more clarification is requested regarding the 
significance of "the number of requests limited and utilized by elements 50, 70, 
72, 90 and 110". 

Next, the differences between Applicants' Claim 1 and the teachings of 
Taylor are considered. 

1 . Applicants' Claim 1 , as amended describes at least one of the 
request types as being associated with multiple thresholds. (Claim 1 step b.) 
For instance, in Applicants' Figure 3, request type "X" is associated with 
Thresholds 1 -3. This capability is not taught by Taylor. In Taylor, read requests 
are associated with a "read threshold" defined by the allowed readers field 96. 
Any write requests are associated with what might loosely be termed a "write 
threshold" that is always set to "one" by virtue of the fact that only one request 
can gain write access to a shared resource at once. The Taylor system does not 
have the flexibility to allow a request type (e.g., "read" or "write") to be associated 
with multiple thresholds as is described by Applicants' amended Claim 1 . 

2. In addition to the foregoing, in Taylor, there is no step of defining 
multiple thresholds. A read threshold is set by the allowed readers field 96. 
However, the write threshold is not "defined", since it must always be set to 
"one". Therefore, Taylor does not teach defining multiple thresholds. 
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For at least the foregoing reasons, Taylor does not teach each and every 
element of Claim 1 as currently amended, and this rejection should be 
withdrawn. 

Claims 2-13 depend from Claim 1 and are allowable over this rejection 
for at least the reasons set forth in regards to Claim 1 . These Claims include 
additional aspects not taught by Taylor as follows: 

Claim 3 describes tracking a requester that issued a request after a 
determination is made that the request must be retried. In contrast to Applicants' 
system, Taylor merely returns a retry message to a process if a request must be 
retried, but does not track which processes have received such messages. For 
example, in regards to Taylor Figure 4: 

"♦..a retry message is returned (at block 204) to the calling process/thread 
to cause the calling process/thread to retry the request later.* (Taylor 
Paragraph 31.) 

Taylor does not describe any mechanism for maintaining a record of which 
processes and/or threads have received retry messages. For instance, an entry 
for the thread that received a retry message remains on the I/O request list 54 
but this list does not appear to maintain any record of the issuance of the 
message to the thread. For this additional reason, Claim 3 is allowable over this 
rejection. 

Claims 4-8 depend from Claim 3, and describe additional aspects of 
Applicants' system related to tracking which requesters have issued requests 
that must be retried as follows. 

Claim 4 describes allowing a request from such a tracked requester to 
gain access to the resource even if a threshold has been reached- This is not 
taught by Taylor, which describes handling all requesters represented on the I/O 
request list 54 without any regard to whether they have previously received a 
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retry message. (See, for example, Taylor paragraph 36.) In other words, when a 
Taylor process retries its request again, the process may, or may not, gain 
access to the requested resource. However, the process does not receive any 
elevated status to allow it to gain access to the resource regardless of whether 
an applicable threshold has been reached. For this additional reason, Claim 4 is 
allowable over this rejection. 

Claim 5 depends from Claim 4 and describes the aspect wherein a 
requester that is being tracked will no longer be tracked after gaining access to 
the resource. Taylor does not teach this aspect of the invention, and Claim 5 is 
allowable over this rejection for these additional reasons. 

Claim 6 depends from Claim 4 and recites creating a partition that 
includes one or more requesters. A request from a tracked requester is only 
allowed to gain access to a resource if that tracked requester is included within 
the partition. (See, for example, Applicants' Specification page 32 lines 20-25.) 
Nothing in Taylor describes the use of partitions, and selectively allowing 
requests to a resource based on those partitions. For this additional reason, 
Claim 6 is allowable over this rejection. 

Claim 7 depends from Claim 6 and is allowable over this rejection for at 
least the reasons discussed in regards to Claims 1 , 4, and 6. 

Claim 8 depends from Claim 4 and further describes utilizing a 
predetermined priority scheme to select a request from among those submitted 
from tracked requesters. As discussed above in regards to Claim 4, Taylor does 
not track requesters, and therefore does not teach this additional aspect of the 
invention. 

Claim 9 describes retrying the request only if the request is of one or more 
predetermined request types. In contrast, in Taylor, all request types (i.e., both 
read and write requests) are retried. For this additional reason, this Claim is 
allowable over this rejection. 

Claim 10 includes allowing a request to gain access to a resource for 
purposes of allowing the request to be retried. This relates to the aspect of 



14 

PAGE 15/21 * RCVDAT 1/912006 6:59:49 PM [Eastern Standard Time] * SVR:USPTO-EFXRF-6)27 * DNIS:2738300 * CSID:651 635 7990 1 DURATION (mm-ss):06-26 



01/09/2008 MON 18:02 FAX 651 635 7990 



UGS 



12] 016 



Serial No 10/675,784 
Filed 9/30/2003 
Examiner Christopher Shin 



Office Action Response 
January 9, 2006 
Group Art Unit 21 82 



Applicants' invention wherein the shared resource is the TTQ 204 of Applicants' 
Figure 2, and a request must gain access to an entry within the TTQ to be 
retried. (See Applicants' Specification page 35.) In contrast, in Taylor, a request 
that is retried does not gain access to a shared resource. (See, for example, 
Taylor paragraph 31 lines 11-1 6.) For this additional reason, Claim 1 0 is 
allowable over this rejection, which should be withdrawn. 

Claim 1 1 describes that defining the multiple thresholds is programmable. 
In Taylor, there is no defining of multiple thresholds, as discussed in regards to 
Claim 1 . Moreover, the write threshold is implicitly a lways set to "one" (since only 
one write request may be occurring at once. Thus, there is no way to program 
this threshold. Moreover, there appears to be no discussion regarding the ability 
to program the "allowed readers field 96" of Taylor Figure 3. Thus, this additional 
aspect of Applicants' invention related to programming thresholds is not taught 
by Taylor. 

Claim 12 describes programmably associating each threshold with one or 
more of the request types. This is accomplished, for Instance, using storage 
devices 322, 324, and 326 of Figure 3, as described on page 21 lines 12-21 of 
Applicants' Specification. Thus, for instance, a Threshold 1", can be 
programmably associated with request types X, Y and Z, as shown In Figure 3. 
This type of programmable capability is not taught by Taylor. In other words, in 
Tailor, the threshold that is determined by the allowed readers field 96 of Taylor 
Figure 3 is hardcoded to be associated with read requests. Similarly, the 
"threshold" of "one" that is associated with write requests is predetermined (not 
programmably selected) by the fact that only one write request can gain 
exclusive access to a shared resource at once. For the additional reason that 
Taylor does not teach programmably associating request types with thresholds, 
Claim 12 is allowable over this rejection. 

Claim 13 describes the aspect wherein at least one of the thresholds is 
associated with a subset of the request types that are associated with another 
threshold. For example, in Applicants' Figure 3, Threshold 2 is associated with 
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request types X and Y, which is a subset of the request types X, Y, and Z that 
are associated with another threshold, Threshold 1 . This aspect of Applicants' 
invention is not taught by Taylor, which teaches read requests being associated 
with the threshold specified by the allowed readers field 96, and write requests 
being associated with the "threshold" of "one", 

Independent Claim 14 has been amended to include aspects similar to 
those discussed above in regards to Claim 1 . In particular, step a.) describes 
that at least one type of request is associated with multiple ones of the defined 
thresholds. This aspect is shown in Applicants' Figure 3, as discussed above. 
For at least the reasons discussed above in regards to Claim 1 , this Claim is 
allowable over Taylor. 

Claims 15-23 depend from Claim 14 and are allowable for at least the 
reasons discussed in regards to Claims 1 and 14. These Claims include 
additional aspects not taught or suggested by Taylor as follows. 

Claim 15 describes the aspect wherein the thresholds are programmably 
selected. For reasons similar to those discussed in regards to Claim 1 1 above, 
this is not taught by Taylor, and Claim 15 is therefore allowable for this additional 
reason. 

Claim 16 describes the aspect wherein thresholds are programmably 
associated with the request types. For reasons similar to those discussed in 
regards to Claim 12 above, this is not taught by Taylor, and Claim 16 is therefore 
allowable for this additional reason. 

Claim 18 describes retrying requests only for predetermined types of 
requests, which is not taught by Taylor for reasons discussed in regards to Claim 
9. For this additional reason, Claim 18 is allowable over this rejection. 

Claim 19 relates to processing a request even if each threshold 
associated with that request has been reached if that request is submitted by a 
requester that has previously received a retry response. This is not taught by 
Taylor, as discussed above in regards to 4. 
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Claim 20 depends from Claim 19, and further recites using a rotational 
priority scheme to select a requester that has been issued a retry indication so 
that this selected requester may gain access to the resource. As discussed 
above in regards to Claims 4-8, this is not taught by Taylor. 

Claim 21 describes the types of requests that are associated with 
thresholds as being selected from read, write, retry, and high-priority read 
requests. This is not taught by Taylor, which, at most, discloses "thresholds" 
associated with only read and write requests. 

Claims 22 describe the additional aspect of associating all request types 
with a first threshold, a second threshold with a first sub-set of all request types, 
and a third threshold with a sub-set of the first sub-set. This Is shown in 
Applicants 3 Figure 3 f for instance. This is not taught by Taylor, which describes 
having a "read threshold" associated with a "read" type of requests, and a "write 
threshold" of tt one° being associated with a "write" type of requests. 

Claim 23 describes the feature wherein an indication is provided to 
requesters to stop issuing requests if all of the thresholds have been reached. 
This is not taught by Taylor. 

Turning next to independent Claim 24, this Claim has been amended to 
describe one or more storage devices each to store a threshold value. At least 
one type of request is associated with multiple thresholds. As previously 
discussed, this is not taught by Taylor, and this Claim is therefore allowable as 
presently presented. 

Claim 24 further describes live-lock logic that elevates the status of a 
request that is of a type associated with one or more threshold values, thereby 
allowing the request to gain expedited access to the shared resource. The 
Examiner takes Official Notice that the live-lock logic recited in the Claim is 
known in the art, and makes reference to the other art that has been made of 
record, but not relied upon. After reviewing this other art, Applicants' 
Representative disagrees and respectfully requests that in the event this 
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rejection is maintained, the Examiner provides a specific citation to support this 
assertion. 

Claims 25-32 depend from Claim 24 and are allowable for the reasons 
discussed in regards to Claim 24. These Claims include additional aspects of 
Applicants' invention not taught by Taylor. For example, Claim 26 describes the 
live-lock logic as including a storage device that tracks each requester issued a 
retry indication. For reasons similar to those discussed above in regards to 
Claim 3 et seq., this type of tracking of requesters that have received retry 
indications is not taught by Taylor. Claim 26 further describes logic that elevates 
a retried request so that it may gain access to the shared resource even if all 
threshold values with which it is associated have been reached. For reasons 
similar to those discussed in regards to Claim 19, this is not taught by Taylor 
Thus, for at least these additional reasons, Claim 26 is allowable over Taylor. 

Claims 27 and 28 depend from Claim 26 and are allowable for at least the 
reasons discussed in regards to the independent Claims, and to Claim 26. 

Claim 29 describes one or more storage devices (e.g., devices 322, 324, 
326 of Figure 3) to store an indication of the types of requests that are associated 
with the threshold values. As described in regards to Claim 12, this is not taught 
by Taylor. 

Claim 30 recites a programming interface to programmably select the 
request types and the thresholds. This is not taught by Taylor, as described in 
regards to Claims 1 5 and 16 above. 

Independent Claim 31 describes aspects similar to Claims 1,14, and 24, 
and is allowable over Taylor for at least the reasons discussed above in regards 
to those Claims. 

Claim 32 depends from Claim 31 and is allowable for at least the reasons 
discussed in regards to Claim 31 . Claim 32 further describes the live-lock means 
for elevating the status of a request to allow it to gain access to requested 
resources regardless of whether the request is of a type that is only associated 
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with threshold values that have been met. As discussed above, Taylor does not 
teach this aspect of the invention. Moreover, Applicants' Representative 
disagrees with the Examiner's taking of Official Notice, and respectfully requests 
production of a reference in regards to this aspect if this rejection is maintained. 
For this additional reason, Claim 32 is allowable over Taylor. 

To summarize the foregoing, it is believed that this response overcomes 
all rejections raised in the Office Action. It is therefore requested that those 
rejections be withdrawn, and a Notice of Allowance be issued in the subject case. 
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Conclusion 



This amendment is filed in response to an Office Action mailed 9/9/2005. 
In this Office Action, Claims 1-32 were rejected. Claims 1-32 remain pending. In 
the amendment set forth above, Claims 1 , 2, 4-6, 8, 10, 14, 24, and 31 are 
amended, and the remaining Claims are as previously presented. In view of the 
amendments to the Claims and the comments set forth above, it is respectfully 
submitted that the Claims are in condition for allowance, and a Notice of 
Allowance is therefore respectfully requested. If the Examiner has questions or 
comments regarding any of the foregoing, a call to the undersigned is 
encouraged and welcomed. 



Beth L McMahon 
Attorney for Applicants 
Reg. No. 41,987 
Tele No. (651)635-7893 

Unisys Corporation 

M.S. 4773 

P.O. Box 64942 

St. Paul, MN 55164-0942 
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